home *** CD-ROM | disk | FTP | other *** search
/ PC World 2000 February / PCWorld_2000-02_cd.bin / Software / Servis / FFE / COMM.SWG / 0006_JAM Messages.pas < prev    next >
Pascal/Delphi Source File  |  1997-05-11  |  29KB  |  620 lines
  1. Filename....: JAM-001
  2. Rev.........: 001
  3. Dated.......: 93-07-01
  4. Status .....: Released
  5. Subject.....: JAM message base proposal
  6. Author......: Joaquim Homrighausen
  7. Co-Authors..: Andrew Milner, Mats Birch, Mats Wallin
  8.  
  9.     ---------------------------------------------------------------------
  10.                                   JAM(mbp)
  11.                 The Joaquim-Andrew-Mats Message Base Proposal
  12.     ---------------------------------------------------------------------
  13.             Copyright 1993 Joaquim Homrighausen, Andrew Milner,
  14.                            Mats Birch, Mats Wallin.
  15.                              ALL RIGHTS RESERVED.
  16.     ---------------------------------------------------------------------
  17.  
  18.  
  19.     =====================================================================
  20.     Restrictions
  21.     ---------------------------------------------------------------------
  22.  
  23. JAM  may  be used by any developer  as  long as these specifications are
  24. followed  exactly.  JAM may be used  free-of-charge by any developer for
  25. any purpose, commercially or otherwise.
  26.  
  27. This  document  may be freely copied  and distributed, but must NEVER be
  28. distributed  in  a  modified form. If  you  have an enhancement request,
  29. please contact the author of this document; do not change it yourself.
  30.  
  31. All  applications  that  support JAM must  include  one of the following
  32. notices  in  their documentation and  somewhere  in the product's credit
  33. section:
  34.  
  35.     "JAM(mbp) - Copyright 1993 Joaquim Homrighausen, Andrew Milner,
  36.                                Mats Birch, Mats Wallin.
  37.                                ALL RIGHTS RESERVED."
  38.  
  39.     or
  40.  
  41.     "This product uses the JAM(mbp) API -
  42.      Copyright 1993 Joaquim Homrighausen, Andrew Milner, Mats Birch,
  43.                     Mats Wallin. ALL RIGHTS RESERVED."
  44.  
  45.     No organization, company, person, entity, or other being may impose
  46.     any fees for any reason for providing this document or the
  47.     accompanying API. This document and the accompanying API may not be
  48.     sold or otherwise transferred for personal or company gain under any
  49.     circumstances.
  50.  
  51.     =====================================================================
  52.     Definitions and general notes
  53.     ---------------------------------------------------------------------
  54.     CURRENTREV                1
  55.  
  56.     JAM                       The JAM message base format.
  57.  
  58.     CRC                       Cyclic Redundancy Check. All CRC values
  59.                               calculated on strings must assume that the
  60.                               data within the string has been converted
  61.                               to lowercase (A-Z = a-z).
  62.  
  63.     CRC-32                    32-bit CRC (as used in the Zmodem file
  64.                               transfer protocol) value. The polynom for
  65.                               a CRC-32 is edb88320H and the CRC-32 seed
  66.                               is -1L (ffffffffH).
  67.  
  68.     uchar                     Unsigned 8-bit value
  69.  
  70.     ushort                    Unsigned 16-bit value
  71.  
  72.     ulong                     Unsigned 32-bit value
  73.  
  74.     UNIX date                 An ulong representing the number of seconds
  75.                               since midnight, January 1, 1970. UNIX-style
  76.                               dates is the only form of time stamps used
  77.                               in JAM (1).
  78.  
  79.     Message #                 The physical record number within the index
  80.                               file is used as a message number. The
  81.                               lowest message number is one (1) and the
  82.                               highest message number is 4294967295
  83.                               (ffffffffH).
  84.  
  85.     FTN                       FidoNet Technology Network
  86.  
  87.     FTS                       FidoNet Technical Standard
  88.  
  89.     (1) All timestamps created locally (i.e. those not imported from
  90.         other systems) are stored in local time.
  91.  
  92.     =====================================================================
  93.     Files
  94.     ---------------------------------------------------------------------
  95.     Each conference is made up from four files. How and where these files
  96.     are stored and named is implementation dependant. The only file with
  97.     a fixed minimum size is the .JHR (header data) file. It has a 1024-
  98.     byte block used to hold information about a specific message area as
  99.     described later.
  100.  
  101.     filename.JHR - Message header data
  102.     filename.JDT - Message text data
  103.     filename.JDX - Message index
  104.     filename.JLR - Lastread information
  105.  
  106.     A future revision of JAM may also include a file that holds the
  107.     following three items:
  108.  
  109.       - The highest assigned user number
  110.       - The last generated message ID
  111.       - A global conference list with the conference name, description,
  112.         and physical location of the message base.
  113.  
  114.     =====================================================================
  115.     .JHR file header
  116.     ---------------------------------------------------------------------
  117.     Below is the format of the 1024-byte record at the beginning of all
  118.     .JHR files. The first actual message header starts at offset 1024 in
  119.     the .JHR file.
  120.  
  121.     FixedHeaderInfoStruct:
  122.         ulong   Signature;       // <J><A><M> followed by <NUL>
  123.         ulong   datecreated;     // Creation date
  124.         ulong   modcounter;      // Update counter
  125.         ulong   activemsgs;      // Number of active (not deleted) msgs
  126.         ulong   passwordcrc;     // CRC-32 of password to access
  127.         ulong   basemsgnum;      // Lowest message number in index file
  128.         uchar   RESERVED[1000];  // Reserved space
  129.     end;
  130.  
  131.     MODCOUNTER must be incremented and updated on disk each time an
  132.     application modifies the contents of the message base. When it
  133.     reaches ffffffffH, it wraps to zero.
  134.  
  135.     ---------------------------------------------------------------------
  136.     BaseMsgNum                        Lowest message number in index file
  137.     ---------------------------------------------------------------------
  138.     This field determines the lowest message number in the index file.
  139.     The value for this field is one (1) when a message area is first
  140.     created. By using this field, a message area can be packed (deleted
  141.     messages are removed) without renumbering it. If BaseMsgNum contains
  142.     500, the first index record points to message number 500.
  143.  
  144.     BaseMsgNum has to be taken into account when an application
  145.     calculates the next available message number (for creating new
  146.     messages) as well as the highest and lowest message number in a
  147.     message area.
  148.  
  149.     ---------------------------------------------------------------------
  150.     ????????.JHR                                          Message headers
  151.     ---------------------------------------------------------------------
  152.     The .JHR file contains none or more Header records. Each record
  153.     define one message and contains information about the message and its
  154.     text (if any). The Header record is of variable length. The layout of
  155.     the Header record follows.
  156.  
  157.     MessageHeader:
  158.         MessageFixedHeader:
  159.             ulong  Signature;    // <J><A><M> followed by <NUL>
  160.             ushort Revision;     // Revision level of header          (1)
  161.             ushort ReservedWord; // Reserved for future use
  162.             ulong  SubfieldLen;  // Length of subfields               (2)
  163.             ulong  TimesRead;    // Number of times message read
  164.             ulong  MSGIDcrc;     // CRC-32 of MSGID line              (3)
  165.             ulong  REPLYcrc;     // CRC-32 of REPLY line              (3)
  166.             ulong  ReplyTo;      // This msg is a reply to..
  167.             ulong  Reply1st;     // First reply to this msg
  168.             ulong  Replynext;    // Next msg in reply chain
  169.             ulong  DateWritten;  // When msg was written
  170.             ulong  DateReceived; // When msg was read by recipient
  171.             ulong  DateProcessed;// When msg was processed by tosser/
  172.                                  // scanner
  173.             ulong  MessageNumber;// Message number (1-based)
  174.             ulong  Attribute;    // Msg attribute, see "Msg Attributes"
  175.             ulong  Attribute2;   // Reserved for future use
  176.             ulong  Offset;       // Offset of text in ????????.JDT file
  177.             ulong  TxtLen;       // Length of message text
  178.             ulong  PasswordCRC;  // CRC-32 of password to access message
  179.             ulong  Cost;         // Cost of message
  180.         end;
  181.         SubField1                // Extra fields as defined below
  182.         .
  183.         .
  184.         SubFieldXX
  185.     end;
  186.  
  187.     (1) This field is intended for future revisions of the specifications
  188.         to allow the use of a different fixed-length binary message
  189.         header. The current revision level is one (1).
  190.  
  191.     (2) The SubfieldLen field is set to zero (0) if the header does not
  192.         have any subfield data. I.e. the length of the binary header is
  193.         not included in this field.
  194.  
  195.     (3) When calculating the CRC-32 of the MSGID and REPLY lines, the
  196.         text ^aMSGID: and ^aREPLY: should be removed as well as all
  197.         leading and trailing white space characters.
  198.  
  199.  
  200.     The SubField structure is made up of an ID, a length specifier, and
  201.     a block of data. Zero or more subfields may follow the fixed-length
  202.     binary header. SubFields are not stored in any specific order and
  203.     are not terminated by any specific character unless otherwise
  204.     specified.
  205.  
  206.     SubField:
  207.         ushort  LoID;            // Field ID, 0-65535
  208.         ushort  HiID;            // Reserved for future use
  209.         ulong   datlen;          // Length of buffer that follows
  210.         uchar   Buffer[datlen];  // DATLEN bytes of data
  211.     end;
  212.  
  213.     ---------------------------------------------------------------------
  214.     Defined LoID codes
  215.     ---------------------------------------------------------------------
  216.  
  217.     ID=0, Name=OADDRESS
  218.  
  219.     A network address. This is used to specify the originating address.
  220.     More than one OADDRESS field may exist. DATLEN must not exceed 100
  221.     characters. For a FidoNet-style address, this field must follow the
  222.     ZONE:NET/NODE.POINT@DOMAIN format where .POINT is excluded if zero
  223.     and @DOMAIN is excluded if unknown.
  224.  
  225.  
  226.     ID=1, Name=DADDRESS
  227.  
  228.     A network address. This is used to specify the destination address.
  229.     More than one DADDRESS field may exist (e.g. carbon copies). DATLEN
  230.     must not exceed 100 characters. For a FidoNet-style address, this
  231.     field must follow the ZONE:NET/NODE.POINT@DOMAIN format where .POINT
  232.     is excluded if zero and @DOMAIN is excluded if unknown.
  233.  
  234.  
  235.     ID=2, Name=SENDERNAME
  236.  
  237.     The sender (author) of the message. DATLEN must not exceed 100
  238.     characters.
  239.  
  240.  
  241.     ID=3, Name=RECEIVERNAME
  242.  
  243.     The recipient of the message. DATLEN must not exceed 100 characters.
  244.  
  245.  
  246.     ID=4, Name=MSGID
  247.  
  248.     Used to store the message identification data. All data not relevant
  249.     to the actual ID string, including leading and trailing white space
  250.     characters should be removed. DATLEN must not exceed 100 characters.
  251.  
  252.  
  253.     ID=5, Name=REPLYID
  254.  
  255.     Used to store the message reply data. All data not relevant to the
  256.     actual reply string, including leading and trailing white space
  257.     characters should be removed. DATLEN must not exceed 100 characters.
  258.  
  259.  
  260.     ID=6, Name=SUBJECT
  261.  
  262.     The subject of the message. DATLEN must not exceed 100 characters.
  263.     Note that this field may not be used for FidoNet-style file attaches
  264.     or file requests.
  265.  
  266.  
  267.     ID=7, Name=PID
  268.  
  269.     Used to store the FTN PID kludge line. Only the actual PID data is
  270.     stored and ^aPID: is stripped along with any leading and trailing
  271.     white space characters. DATLEN must not exceed 40 characters.
  272.  
  273.  
  274.     ID=8, Name=TRACE
  275.  
  276.     This is also referred to as ^aVia information in FTNs. It contains
  277.     information about a system which the message has travelled through.
  278.     The format of the field is <YYYYMMDDHHMMSS><Network address> where:
  279.  
  280.        YYYY is the year (1992-9999)
  281.          MM is the month (01-12)
  282.          DD is the day (01-31)
  283.          HH is the hour (00-23)
  284.          MM is the minute (00-59)
  285.          SS is the second (00-59)
  286.  
  287.     The timestamp is stored in ASCII (0-9) characters. The network
  288.     address is the address of the system. It is expressed in ASCII
  289.     notation in the native format of the forwarding system.
  290.  
  291.  
  292.     ID=9, Name=ENCLOSEDFILE
  293.  
  294.     A file attached to the message. Only one filename may be specified
  295.     per subfield. No wildcard characters are allowed. If this subfield
  296.     is present in a message header, the ATTRIBUTE must include the
  297.     MSG_FILEATTACH bit.
  298.  
  299.  
  300.     ID=10, Name=ENCLOSEDFILEWALIAS
  301.  
  302.     Identical to ENCLOSEDFILE with the exception that the filename is
  303.     followed by a <NUL> (00H) and an alias filename to be transmited to
  304.     the remote system in place of the local name of the file.
  305.  
  306.  
  307.     ID=11, Name=ENCLOSEDFREQ
  308.  
  309.     A request for one or more files. Only one filemask may be specified
  310.     per subfield. If the filemask contains a complete path, it is to be
  311.     regarded as an update file request. If this subfield is present in a
  312.     message header, the ATTRIBUTE must include the MSG_FILEREQUEST bit.
  313.     To indicate that a password is to be transmitted along with the
  314.     request, a <NUL> (00H) character followed by the password is
  315.     appended. E.g. SECRET*.*<NUL>MYPASSWORD.
  316.  
  317.  
  318.     ID=12, Name=ENCLOSEDFILEWCARD
  319.  
  320.     One or more files attached to the message. Only one filename may be
  321.     specified per subfield. Wildcard characters are allowed. If this
  322.     subfield is present in a message header, the ATTRIBUTE must include
  323.     the MSG_FILEATTACH bit.
  324.  
  325.  
  326.     ID=13, Name=ENCLOSEDINDIRECTFILE
  327.  
  328.     One or more files attached to the message. The filename points to an
  329.     ASCII file with one filename entry per line. If alias filenames are
  330.     to be used, they are specified after the actual filename and
  331.     separated by a <NUL> (00H) character, e.g. C:\MYFILE.LZH<NUL>NEWS.
  332.     Wildcard characters are not allowed.
  333.  
  334.  
  335.     ID=1000, Name=EMBINDAT
  336.  
  337.     Reserved for future use.
  338.  
  339.  
  340.     ID=2000, Name=FTSKLUDGE
  341.  
  342.     An FTS-compliant "kludge" line not otherwise represented here. All
  343.     data not relevant to the actual kludge line, including leading and
  344.     trailing white space and ^A (01H) characters should be removed.
  345.     DATLEN must not exceed 255 characters. The FTS kludges INTL, TOPT,
  346.     and FMPT must never be stored as separate SubFields. Their data must
  347.     be extracted and used for the address SubFields.
  348.  
  349.  
  350.     ID=2001, Name=SEENBY2D
  351.  
  352.     Used to store two-dimensional (net/node) SEEN-BY information often
  353.     used in FTN conference environments. Only the actual SEEN-BY data is
  354.     stored and ^aSEEN-BY: or SEEN-BY: is stripped along with any leading
  355.     and trailing white space characters.
  356.  
  357.  
  358.     ID=2002, Name=PATH2D
  359.  
  360.     Used to store two-dimensional (net/node) PATH information often used
  361.     in FTN conference environments. Only the actual PATH data is stored
  362.     and ^aPATH: is stripped along with any leading and trailing white
  363.     space characters.
  364.  
  365.  
  366.     ID=2003, Name=FLAGS
  367.  
  368.     Used to store the FTN FLAGS kludge information. Note that all FLAG
  369.     options that have binary representation in the JAM message header
  370.     must be removed from the FLAGS string prior to storing it. Only
  371.     the actual flags option string is stored and ^aFLAGS is stripped
  372.     along with any leading and trailing white space characters.
  373.  
  374.  
  375.     ID=2004, Name=TZUTCINFO
  376.  
  377.     Time zone information. This subfield consists of four mandatory
  378.     bytes and one optional. The first character may be a plus (+) or a
  379.     minus (-) character to indicate a location east (plus) or west
  380.     (minus) of UTC 0000. The plus character is implied unless the first
  381.     character is a minus character. The following four bytes must be
  382.     digits in the range zero through nine and indicates the offset in
  383.     hours and minutes. E.g. 0100 indicates an offset of one hour east of
  384.     UTC.
  385.  
  386.     ---------------------------------------------------------------------
  387.     Message attributes
  388.     ---------------------------------------------------------------------
  389.     MSG_LOCAL       (0x00000001L)   // Msg created locally
  390.     MSG_INTRANSIT   (0x00000002L)   // Msg is in-transit
  391.     MSG_PRIVATE     (0x00000004L)   // Private
  392.     MSG_READ        (0x00000008L)   // Read by addressee
  393.     MSG_SENT        (0x00000010L)   // Sent to remote
  394.     MSG_KILLSENT    (0x00000020L)   // Kill when sent
  395.     MSG_ARCHIVESENT (0x00000040L)   // Archive when sent
  396.     MSG_HOLD        (0x00000080L)   // Hold for pick-up
  397.     MSG_CRASH       (0x00000100L)   // Crash
  398.     MSG_IMMEDIATE   (0x00000200L)   // Send Msg now, ignore restrictions
  399.     MSG_DIRECT      (0x00000400L)   // Send directly to destination
  400.     MSG_GATE        (0x00000800L)   // Send via gateway
  401.     MSG_FILEREQUEST (0x00001000L)   // File request
  402.     MSG_FILEATTACH  (0x00002000L)   // File(s) attached to Msg
  403.     MSG_TRUNCFILE   (0x00004000L)   // Truncate file(s) when sent
  404.     MSG_KILLFILE    (0x00008000L)   // Delete file(s) when sent
  405.     MSG_RECEIPTREQ  (0x00010000L)   // Return receipt requested
  406.     MSG_CONFIRMREQ  (0x00020000L)   // Confirmation receipt requested
  407.     MSG_ORPHAN      (0x00040000L)   // Unknown destination
  408.     MSG_ENCRYPT     (0x00080000L)   // Msg text is encrypted          (1)
  409.     MSG_COMPRESS    (0x00100000L)   // Msg text is compressed         (1)
  410.     MSG_ESCAPED     (0x00200000L)   // Msg text is seven bit ASCII    (1)
  411.     MSG_FPU         (0x00400000L)   // Force pickup
  412.     MSG_TYPELOCAL   (0x00800000L)   // Msg is for local use only
  413.     MSG_TYPEECHO    (0x01000000L)   // Msg is for conference distribution
  414.     MSG_TYPENET     (0x02000000L)   // Msg is direct network mail
  415.     MSG_NODISP      (0x20000000L)   // Msg may not be displayed to user
  416.     MSG_LOCKED      (0x40000000L)   // Msg is locked, no editing possible
  417.     MSG_DELETED     (0x80000000L)   // Msg is deleted
  418.  
  419.     (1) This revision of JAM does not include compression, encryption, or
  420.         escaping. The bits are reserved for future use.
  421.  
  422.     =====================================================================
  423.     ????????.JDT                                             Message text
  424.     ---------------------------------------------------------------------
  425.     The .JDT file contains the text of messages. The text is stored as an
  426.     stream of seven or eight bit ASCII data. Allowed characters in the
  427.     text are 00H through ffH unless the header ATTRIBUTE field has the
  428.     MSG_ESCAPED bit enabled, in which case the legal range of data is 20H
  429.     through 7eH.
  430.  
  431.     An escaped character is stored as \<hex> where <hex> is the two digit
  432.     hexadecimal ASCII value of the character. A single \ is stored as \\
  433.     or \5C. The case of the hexadecimal ASCII value is irrelevant, i.e.
  434.     5c is treated as 5C.
  435.  
  436.     =====================================================================
  437.     ????????.JDX                                            Message index
  438.     ---------------------------------------------------------------------
  439.     The .JDX file is used to quickly locate messages for any given user
  440.     name or to locate a message with a specific number. Each record in
  441.     the file consists of two ulongs. The first ulong holds the CRC-32 of
  442.     the recipient's name (lowercase), the second ulong holds the
  443.     physical offset of the message header in the .JHR (header) file.
  444.  
  445.     The record number (+BaseMsgNum) within the .JDX file determines a
  446.     message's number.
  447.  
  448.     If both ulongs are -1 (ffffffffH), there is no corresponding message
  449.     header.
  450.  
  451.     =====================================================================
  452.     ????????.JLR                                         Lastread storage
  453.     ---------------------------------------------------------------------
  454.     The .JLR file is used to maintain a user's position within a message
  455.     area. The layout of the "lastread" record follows. One record per
  456.     user is required.
  457.  
  458.     LastRead:
  459.         ulong   UserCRC;         // CRC-32 of user name (lowercase)   (1)
  460.         ulong   UserID;          // Unique UserID
  461.         ulong   LastReadMsg;     // Last read message number
  462.         ulong   HighReadMsg;     // Highest read message number
  463.     end;
  464.  
  465.     (1) The functions to convert a string to lowercase characters that
  466.         are provided in the API will only convert characters A-Z (into
  467.         a-z). It is required that this convention is followed by all
  468.         applications.
  469.  
  470.     The UserID field is a unique number for each user. If the "lastread"
  471.     record is deleted, UserCRC and UserID are both set to -1
  472.     (ffffffffH). An application may not depend on any specific order in
  473.     the .JLR file. A user's "lastread" record may appear anywhere in the
  474.     file and must be searched for when retrieving it and when storing an
  475.     updated record.
  476.  
  477.     =====================================================================
  478.     Updating message headers
  479.     ---------------------------------------------------------------------
  480.     If a header record grows after is has been retrieved from the .JHR
  481.     file, it must be appended to the end of the .JHR file since it would
  482.     overwrite the following header otherwise. The .JDX file must be
  483.     properly updated to indicate the new location of the header record.
  484.     The old header record must be changed to indicate that it has been
  485.     deleted by setting the MSG_DELETED bit in the Attribute field and the
  486.     TextLen field to zero (to prevent a maintenance program from removing
  487.     the message text that is now pointed to by another header).
  488.  
  489.     =====================================================================
  490.     Message base sharing and locking
  491.     ---------------------------------------------------------------------
  492.     To allow several programs to access the message base at any given
  493.     time, region locking is used to protect the message base from being
  494.     corrupted during updates.
  495.  
  496.     When an application needs to write to any of the message base files,
  497.     it must first attempt to lock the first byte of the .JHR (header)
  498.     file. If the lock call fails, the application must either fail or
  499.     attempt to lock the file again. The message base files may under no
  500.     circumstances be updated if the application cannot successfully lock
  501.     the .JHR file.
  502.  
  503.     Note that data acquired (read) from the message base may not be used
  504.     when writing data to the message base, unless the application has
  505.     maintained a lock of the message base from the time the data was
  506.     acquired or the MODCOUNTER field is the same as when the data was
  507.     acquired.
  508.  
  509.     The application must open the files in shareable (DENYNONE) read/
  510.     write or readonly mode. The only exception to this is an application
  511.     that requires exclusive access to the message base, such as a message
  512.     base maintenance utility, it should open the files in non-shareable
  513.     (DENYALL) read/write mode.
  514.  
  515.     =====================================================================
  516.     Reply threads and linking
  517.     ---------------------------------------------------------------------
  518.     JAM introduces a new reply link pointer, not commonly used today.
  519.     This section is an attempt to describe how reply threads, reply
  520.     linking, and this new reply link pointer is implemented in JAM.
  521.  
  522.     One of the major differences is that reply threads in JAM are not
  523.     based on similar or identical subjects of messages since this method
  524.     does not allow for proper reply threads.
  525.  
  526.     The method used in JAM is based on the immediate relation between any
  527.     given message and direct replies to it. This is supported by many
  528.     message editors by using the MSGID and REPLY FTS kludge fields. These
  529.     are common, although expressed differently, in messages not based on
  530.     FidoNet technology, such as RFC-822. The obvious advantages include
  531.     allowing a program to easily find the original message to a reply,
  532.     and to find all replies to any given message.
  533.  
  534.     The reply thread information consists of three fields: ReplyTo,
  535.     Reply1st, and ReplyNext. The reason for three fields, as opposed to
  536.     just two, is that with two fields, it is only possible to keep track
  537.     of the original message of a reply (which is sufficient) and one
  538.     reply to any given message (which is not sufficient). With three
  539.     fields, it is possible to maintain a thread of any number of replies
  540.     to any given message.
  541.  
  542.     In the description of the different fields below, the following
  543.     messages and message numbers will be referred to:
  544.  
  545.       1 -> 2 -> 4 -> 5
  546.       :    :
  547.       :    +--> 8
  548.       :
  549.       +--> 3 -> 7
  550.       :
  551.       +--> 6
  552.  
  553.     Message number two, three, and six are replies to message number one.
  554.     Message number four and eight are replies to message number two.
  555.     Message number seven is a reply to message number three.
  556.     Message number five is a reply to message number four.
  557.  
  558.     ---------------------------------------------------------------------
  559.     ReplyTo
  560.     ---------------------------------------------------------------------
  561.     This field holds the number of the message that this message is a
  562.     reply to. In the example above, the ReplyTo field would contain the
  563.     following values:
  564.  
  565.     Message number one would contain zero; message number two, three, and
  566.     six, would contain one; message number four and eight would contain
  567.     two; message number seven would contain three, and message number
  568.     five would contain four.
  569.  
  570.     ---------------------------------------------------------------------
  571.     Reply1st
  572.     ---------------------------------------------------------------------
  573.     This field holds the number of the first message that is a reply to
  574.     this message. In the example above, the Reply1st field would contain
  575.     the following values:
  576.  
  577.     Message number one would contain two, message number three would
  578.     contain seven, and message number four would contain five. All other
  579.     messages would contain zero.
  580.  
  581.     ---------------------------------------------------------------------
  582.     ReplyNext
  583.     ---------------------------------------------------------------------
  584.     This field is used to create the actual message thread or chain. In
  585.     the event that there is more than one reply to any given message, it
  586.     is necessary to maintain a thread of all the replies; this is due to
  587.     the fact that the original message can only hold information about
  588.     the first reply (the Reply1st field) to it.
  589.  
  590.     The first reply (which the original message's Reply1st field holds),
  591.     has its ReplyNext field pointing to the second reply, the second
  592.     reply's ReplyNext field poinst to the third reply, and so on.
  593.  
  594.     In the example above, the ReplyNext field would contain the following
  595.     values:
  596.  
  597.     Message number two would contain three, message number three would
  598.     contain six, and message number four would contain eight. All other
  599.     messages would contain zero.
  600.  
  601.     =====================================================================
  602.     Contacts
  603.     ---------------------------------------------------------------------
  604.     Joaquim Homrighausen                            Telefax: +352 316 702
  605.     389, route d'Arlon                                Modem: +352 316 702
  606.     L-8011 Strassen                               eMail: 2:270/17@fidonet
  607.     Luxembourg                                                joho@abs.lu
  608.  
  609.     Andrew Milner                                   Telefax: +352 251 621
  610.     9a, Boulevard Joseph II                           Modem: +352 251 621
  611.     L-1840 Belair                                 eMail: 2:270/18@fidonet
  612.     Luxembourg                                             andrew@fido.lu
  613.  
  614.     Mats Wallin                                    Telefax: +46 8 6453285
  615.     Förskottsvägen 11                                Modem: +46 8 6453882
  616.     S-126 44 Hägersten                           eMail: 2:201/329@fidonet
  617.     Sweden                                                     mw@fido.lu
  618.  
  619.     // end of file "jam.doc"
  620.